Technical Standards Setting
For over twenty years, I’ve navigated the world of software engineering, first as a builder, then as a leader. One thing that consistently surprises people – and frankly, has surprised me throughout my career – is the often… messy reality of technical standards. We talk about standards as if they’re carved in stone, immutable laws of the digital world. But the truth is far more human, a story of negotiation, compromise, and a surprising degree of trust. And understanding this is critical for any engineering leader.
This isn’t about the technical details of a specific standard (though those are important!). It’s about the process of setting those standards, and why that process matters so much for building effective teams, fostering innovation, and ultimately, delivering quality software.
The Myth of Immutability
We often want standards to be rigid. A clear, definitive guide to “the right way” to do things. This desire for order is understandable. It promises predictability, interoperability, and a reduction in wasted effort. But the history of tech tells a different story. Remember a time when there were 16 competing standards for… well, something? (I’ve certainly seen that many options for seemingly simple things in my career!). Like the multiple competing video codec standards in the early 2000s, the abundance of choices highlights the dynamic nature of innovation and the challenges of achieving consensus.
The anecdote about specs being agreed to with a phone call is particularly telling. In a fast-moving field like software development, detailed, exhaustive documentation often can’t keep pace with reality. What does matter is shared understanding and a willingness to adapt.
This isn’t an argument against documentation. It’s a recognition that documentation is a snapshot in time, and the real “standard” often resides in the collective knowledge and ongoing communication within a team, and the wider industry.
Why So Many Standards? (And Why Does it Matter to You?)
The proliferation of standards isn’t necessarily a bad thing. It reflects experimentation, innovation, and the inherent complexity of building software. However, it does create challenges for engineering leaders. The sheer number of choices can lead to decision fatigue, crippling teams that spend valuable time debating options instead of building. Integration headaches and skill gaps further complicate the landscape. Maintaining compatibility across systems built on different standards requires significant effort and investment.
These challenges underscore the importance of thoughtful consideration and strategic decision-making. It’s not simply about choosing a standard; it’s about choosing the standard that best aligns with your team's goals, resources, and long-term vision.
Leading Through the Messiness
So, what can an engineering leader do? Here's how to navigate the world of technical standards effectively:
- Prioritize Understanding, Not Just Adoption: Don’t simply mandate adherence to a specific standard. Ensure your team understands why that standard was chosen, its benefits, and its limitations. A shallow understanding leads to brittle implementations and future problems.
- Embrace "Good Enough" Standardization: Perfection is the enemy of progress. Sometimes, adopting a widely-used standard with minor modifications is more practical than striving for a theoretically perfect solution. Focus on interoperability and maintainability as key criteria.
- Foster Open Communication: Encourage your team to actively participate in industry discussions and contribute to the evolution of standards. This helps ensure that standards are relevant, practical, and address real-world challenges.
- Cultivate a Culture of Pragmatism: As one business analyst shared with me, sometimes a clear understanding of the desired outcome is more valuable than exhaustive technical specifications. Empower your team to make informed decisions based on context and common sense.
- Recognize the Human Element: Remember that standards are created and maintained by people. Building relationships with industry peers and actively participating in standards bodies can provide valuable insights and influence the direction of future standards. I once saw a critical interoperability issue resolved not through technical debate, but through a quick phone call between two engineers who had a pre-existing working relationship – a testament to the power of human connection.
The Future of "Tech for the Non-Tech"
The question of whether parents will one day prep their kids for tech careers is intriguing. It highlights the increasing importance of digital literacy in all aspects of life. However, I believe the real skill isn't necessarily coding or mastering specific technologies. It’s the ability to understand technology, to critically evaluate its implications, and to adapt to a constantly changing landscape.
This ability to explain technology is also vital. As engineers, we often get caught up in the technical details, forgetting that many stakeholders outside our field need to understand the impact of our work. This is a natural extension of the need to understand standards and communicate their value effectively – both within our teams and to the wider organization.
That's why, as engineering leaders, we have a responsibility to demystify technology and make it accessible to a wider audience. Not by watering down the technical details, but by focusing on the underlying principles and the human needs that technology is meant to serve.
In conclusion, technical standards aren't just about bits and bytes. They’re a reflection of our values, our priorities, and our ability to collaborate effectively. By embracing the messy reality of standards setting and fostering a culture of pragmatism, we can build better software, empower our teams, and create a more collaborative and effective future. The next time your team faces a standards debate, remember that the goal isn’t to find the ‘perfect’ solution, but to build something that works, solves a real problem, and fosters collaboration.